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(57) Abstract: A system ajid user interface integrates and processes 
event associated messages affecting healthcare delivered to apatient 
and supports creation, initiation and modification of currently oper- 
ating workflow processes involving processing of event messages, 
A method for processing an event representing a change in circum- 
stances potentially affecting healthcare delivered to a patient involves 
receiving a message identifying an event potentially affecting health- 
care delivered to a patient Predetermined rules are applied to in- 
terpret the identified event to determine particular tasks to be per- 
formed in response to occurrence of the identified event. The par- 
ticnlar tasks are scheduled to be performed by at least one individ- 
ual in response to the occurrence of the identified event. In addition 
a database containing records indicating active process instances is 
searched to identify active process instances oF a target process to 
be replaced by a process comprising the particular tasks. Also a pa- 
rameter associated with an event is stored at a location available for 
access by multiple different process task sequences 
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A System for Processing Healthcare Related Event Information for 
Use in Scheduling Performance of Tasks 

This is a non-provisional application of provisional application serial 
No. 60/318,664 by S. Brandt et al. filed September 12, 2001, 

Field of the Invention 

This invention concerns a system and user interface supporting 
scheduling a workflow process comprising a set of tasks to be performed by at 
least one individual to support healthcare delivery. 

Background of the Invention 

Modern healthcare requires the concurrent provision of services by 
many health-care workers to many patients. In order to accomplish this, 
healthcare delivery has been organized into specialized departments such as 
nursing, laboratory, and radiology departments. Each department has 
responsibility for accomplishing its particular, often specialized, subset of tasks. 
Unfortunately, this has resulted in fragmented patient care and sub-optimal 
healthcare operations. A single healthcare process such as the ordering and 
administration of a medication, requires the participation of many health-care 
workers, possibly across many departments r and is therefore fraught with 
opportunities for error and delay. 

Clinical and healthcare information systems provide a computerized 
Interface for heaith-care workers to perform individual tasks. However, these 
systems typically have limited capability to manage the sequence of tasks 
involved in healthcare processes. This is particularly true when the processes 
require the involvement of multiple health-care workers. Workflow management 
systems are designed to manage complex processes that include individual work 
steps performed by multiple workers and systems. They allow the customized 
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configuration of these processes, as we|] as continuous monitoring and 
management while the processes are in progress, fn order to optimally employ a 
workflow management system in healthcare, it is desirable that the system 
support configuration of a workflow (i.e. determination of a sequence and 
schedule of tasks to be performed by one or more individuals) at a local level. 
Such a local level may be within a facility where the workflow is to be 
implemented, for example. 

Existing healthcare or clinical information systems provide user 
interfaces for performing individual healthcare tasks and viewing and recording of 
information. This includes, for example, results reporting, goods and services 
ordering, clinical and nursing care documentation, and financial or operational 
data capture. However, existing systems are typically task oriented, and provide 
interfaces for individuals to accomplish specific tasks. As such they fail to provide 
the flexible and comprehensive user interfaces and systems needed to support 
the adequate management of clinical care and documentation processes that 
involve multiple users, and which occur over an extended period of time, and are 
amenable to reengineering. A system according to invention principles addresses 
these deficiencies and derivative deficiencies. Specifically the disclosed system 
supports creation, initiation and modification of workflow processes that sequence 
tasks to be performed by healthcare personnel and also supports the monitoring 
and management of the tasks and of their progress until their successful 
completion. 

Summary of Invention 

A system and user interface integrates and processes event 
associated messages affecting healthcare delivered to a patient and supports 
creation, initiation and modification of currently operating workflow processes 
involving processing of event messages. A method for processing an event 
representing a change in circumstances potentially affecting healthcare delivered 
to a patient involves receiving a message identifying an event potentially affecting 
healthcare delivered to a patient. Particular tasks to be performed are determined 
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and scheduled to be performed by at least one Individual in response to 
occurrence of the identified event 

In a feature of the invention, the method involves searching a 
database containing records indicating active process instances to identify active 
process instances of a target process to be replaced by a process comprising the 
particular tasks. 

In another feature of the inveniion, a parameter associated with an 
event is stored at a location available for access by multiple different process task 
sequences. 

BRIEF DESCRIPTION OF THE DRAWING 

Figure 1 shows an existing healthcare or clinical information system 
for invoking actions in external systems. 

Figure 2 shows a system that allows healthcare enterprises to 
create and configure workflow processes (comprising task sequences to be 
performed} responsive to events generated from a Healthcare Information System 
(HIS), according to invention principles. 

Figure 3 shows a user interface display window for use indicating 
events and associated parameters that are usable in altering workflow processes 
comprising scheduled task sequences, according to invention principles. 

Figure 4 shows a process flowchart for processing an event for use 
in replacing one or more tasks of a scheduled workflow process, according to 
invention principles. 

Figure 5 shows a process flowchart for processing an event and 
associated parameters for use in replacing a scheduled workflow process, 
according to invention principles. 
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Figure 6 shows a workflow and event management system 
responsive to events generated by other workflow processes and responsive to 
events external to an HIS, according to invention principles. 

Figure 7 shows a currently operating Healthcare information System 
(HIS) workflow process responsive to a predetermined event generated by 
another workflow process. 

Figure 8 shows a system for processing an event indication affecting 
a currently operating instance of a Healthcare Information System (HIS) workflow 
process, according to invention principles, 

Detailed Description of the Drawing 

Figure 1 shows an existing healthcare or clinical information system 
for invoking actions in external systems. In such a system, messages identifying 
events or actions taken in a Healthcare Information System (HIS) 12 (perhaps 
involving storage unit 14) in response to user actions 10, are communicated to 
external systems 17-21 through an interface engine 15. An event as used herein 
is an action or occurrence representing a change in circumstances potentially 
affecting healthcare delivered to a patient. An event message identifying such an 
event may be generated due to action by healthcare personnel, by an operating 
process (perhaps for influencing other operating processes), by a non-healthcare 
system such as an administrative application {perhaps involving financial 
transaction information), or by patient monitoring equipment. An event message 
may also be generated by other devices for example: patient locator or proximity 
devices, and medical equipment such as IV pumps. Interface engine 15 may 
comprise a workflow processing application or other application supporting 
communication with external systems 17-21. A workflow as used herein 
comprises a sequence of tasks or operations that are scheduled for performance, 
or are being performed, by one or more entities including individuals, groups of 
individuals, or personnel assigned to perform particular functions or roles. 
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External systems 17-21 comprise a laboratory 17, pharmacy 18 and financiaf 
application {such as for patient service tracking and billing) 21, for example, but 
may also encompass a broader range of systems incfuding any system with which 
HIS 12 performs a transaction or data exchange. Further Healthcare Information 
System (HIS) 12 may comprise other types of information system such as a 
Clinical information System or Critical Care Information System or another 
Information system. Further, in other embodiments HIS 12 may include non- 
healthcare information systems such as financial information systems provided 
that such a system Involves performing a sequence of tasks that is susceptible to 
modification as a result of occurrence of an event. 

The existing systems workflow processing function exemplified in 
the unit 15 function of Figure 1 has a number of deficiencies. These include 
limited flexibility in configuring workflow processes and limited capability for 
creating workflow processes that may be dynamically re-configured in response to 
events. Existing workflow management systems are typically limited in the 
flexibility they allow in configuring workflow processes and in allocating codes for 
identifying processes and events, for example. This is insufficient for healthcare 
applications in which a healthcare enterprise HIS system supplied by one vendor 
is oblivious of workflow process configurations implemented using workflow 
management application software provided by a different vendor. Jn addition, 
existing workflow management systems typically assume that individual work 
processes are autonomous and are unaffected by other running processes. In 
contrast, real healthcare processes constantly affect each other. For example, a 
patient being taken to radiology for a diagnostic study interferes with the 
administration of intravenous medication in the patient's room, Further, the 
complexity of modern healthcare enterprises means that a healthcare workflow 
process may need to be responsive to multiple different healthcare events, and 
also that a single event may impact multiple different concurrently operating 
healthcare processes. For example, an order to discharge a patient from a 
hospital may have multiple workflow processes associated with it, such as 
management of discharge medications, cancellation of dietary orders, and 
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initiaiization of a discharge billing process. Further, a single workflow 
management process to cancel and to re-issue dietary orders may occur as a 
consequence of a discharge order, an order of "NPO" or nothing by mouth, or the 
transfer of a patient to surgery, for example. This implies a more sophisticated 
mechanism is required for invoking workflow processes than existing workflow 
management systems currently support. The disclosed system supports creation 
and configuration of healthcare processes that interact with each other and 
respond to changes and events originating in other processes. 

The disclosed system and user interface integrates and processes 
event associated messages affecting healthcare delivered to a patient. The 
system provides a means for ensuring that messages are generated upon 
occurrence of selected events and for forwarding those generated messages to a 
workflow management system. The system also provides a method and user 
interface for linking a configured workflow process to a healthcare event so that a 
selected workflow process adapts upon occurrence of the event. For this purpose 
the system advantageously categorizes and filters events generated by an HIS to 
ensure that the events affecting the configured workflow process, or other 
healthcare workflow processes, are forwarded to the workflow management 
system. The filter thereby excludes a potentially targe volume of event items of no 
consequence to system workflow processes. Thfs significantly reduces the 
workload involved. Upon occurrence and detection of a user selected particular 
event, the system further allows a user to predetermine which one of multiple 
different workflow processes is Implemented. Thereby, at user discretion, 
occurrence of an event may result in a default workflow process or another 
different workflow process being implemented. Further, the selected workflow 
process may also be further adapted upon occurrence of additional events. This 
enables conventional workflow processes to be employed as default processes or 
allows dynamically adaptive workflow processes to be implemented or allows both 
types of process to operate in parallel. This supports flexible workflow 
management and enables a considerable degree of flexibility in workflow process 
implementation and re-engineering upon healthcare system alteration or 
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modification. 

Figure 2 shows a system that allows healthcare enterprises to 
create and configure workflow processes (comprising task sequences to be 
performed) and to link the created workflow processes to events generated from 
HIS 12. In response to user actions 10, HIS 12 using storage 14 generates event 
messages and communicates them to event monitor 25 (in event processor 28). 
The event messages include event identifiers and metadata that identify user 
actions and other occurrences associated with healthcare delivery and support 
that take place in a healthcare enterprise and potentially affect healthcare 
delivered to a patient. Event messages provided by HIS 12 may identify user 
orders, documentation, and reports. Examples include such items as: a physician 
order for "Gentamicm 120 mg IV Stat then 80 mg every 8 hours", a nursing 
documentation of "2 cm area of redness on the patient's left lateral heel", or a. 
microbiology report of "methacillin resistant staph aureus" cultured from a skin 
lesion of a newborn in the level one nursery. Such orders and observations 
require action by healthcare personnel and are advantageously processed by the 
Figure 2 system. 

In a conventional system a Gentamicin order^ for example, is simply 
encoded In Health Level 7 (HL 7) format and forwarded to a pharmacy system for 
preparation of the drug. In contrast, the system of Figure 2 creates and manages 
a workflow that accommodates the healthcare implications and consequences of 
such an order. The order intends a sequence of at least 7 events, for example, 
including the mixing of the medication, its transport to the patient's room, the 
insertion of an IV line if required, the infusion of the drug, nursing oversight to 
ensure that the drug infuses properly, nursing documentation of the infusion, and 
adjustment of subsequent doses to maintain the appropriate interval* In the case 
of receiving nursing documentation or a microbiology report event messages, the 
Figure 2 system implements a consistent set of workflow processes for 
responding to the nurse observations and the outcome of the microbiology test. In 
the first case, the Figure 2 system initiates a process including a scheduled task 
to protect the patient from skin breakdown and in the second case, the Figure 2 
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system initiates a process including a scheduled task to implement an isolation 
procedure within a nursery. 

The event messages also include parameter values and other 
metadata that is to be provided to a particuiar workflow process application in 
response to occurrence of a corresponding particular event. In the case of a drug 
order event, for example, the parameters may Include a patient identifier, a drug 
identifier, drug strength, method of administering the drug, and dosing 
information. In the case of a nursing documentation of skin findings report event, 
the parameters may include a patient identifier, a finding identifier, descriptors, 
and site identifiers. Event monitor 25 categorizes and fitters the received event 
messages and forwards those messages that are associated with registered 
workflow processes. Other event messages that are not associated with 
registered workflow processes are excluded. For this purpose event monitor 25 
maintains a database including a map associating events, event identifiers and 
parameter identifiers with workflow processes. The map is used in determining 
parameter values and other data that is to be provided to a particular workflow 
process applfcation in response to occurrence of a corresponding particular event, 

In response to receiving an event message, event monitor 25 
examines its map to determine whether a workflow process is associated with the 
event identified by the event identifier in the received message. If the identified 
event is associated with a particular workflow process (decision 34 of Figure 2), 
event monitor 25 examines any parameters associated with the identified event 
and conveyed in the received event message from HIS 12. Specifically, monitor 
25 determines if received event parameter values match predetermined criteria 
associated with the corresponding event. The predetermined criteria are specified 
during an event registration process during which a workflow process is 
associated with one or more identified events and associated event parameters. 
Thereby a workflow process is associated with one or more events' and related 
event parameter values. If event monitor 25, using its map, finds that no workflow 
process is associated with the identified event (decision 32 of Figure 2), it 
disregards the event message and returns a message to HIS 12 instructing HIS 
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12 to proceed with default processing. Such default processing may involve HIS 
12 communicating via messages 43 with external systems 17-21 through an 
interface engine 19 in support of a default workflow process in similar fashion to 
that described in connection with Figure 1, for example. 

Event monitor 25 performs further operations if it determines in 
decision 34 that the identified event is associated with a particular workflow 
process and the received event parameter values are within a predetermined 
range. Specifically, monitor 25 determines from predetermined user selection 
information whether a default process is to be replaced by a workflow managed 
process that is invoked as a consequence of the event. If it is not to be replaced, 
monitor 25 returns a message to HIS 12 instructing HIS 12 to proceed with the 
default workflow processing. If it is to be replaced HiS 12 surrenders processing 
to event monitor 25 and the particular workflow process associated with the 
identified event by the monitor 25 internal map is implemented. Further, event 
monitor 25 provides rufes engine 30 with the event identifier and associated event 
parameter values for use in implementing the particular workflow process. 

In addition, monitor 25 also determines from predetermined user 
selection information whether there is an executable procedure {e.g. a script file) 
associated with the particular workflow process. Such a procedure may 
incorporate logic determining how an event associated workflow process is 
initiated or processed, for example. If there is such an associated procedure, 
monitor 25 also provides the procedure to rules engine 30 for execution. 
Alternatively the procedure may be pre-stored in rules engine 30, in which case 
monitor 25 commands engine 30 to initiate execution of the procedure. Rules 
engine 30 uses the information and commands received from monitor 25 to call 
the Workflow Management System 36 and instruct it to implement the event 
associated particular workflow process 31. It does this by creating and initiating a 
copy (an instance) of the desired event associated particular workflow process. In 
a complex system a workflow process may be implemented multiple times (i.e. as 
multiple instances) for different patients, for example. Therefore, process copies 
are made of a template process and the copies (instances) are the processes that 



9 



WO 03/023551 



PCT/US02/23496 



are actually implemented. The multiple workflow process instances may or may 
not be in concurrent operation. The implemented workflow process may also be 
configured to communicate with users and other systems (e.g. laboratory 17, 
pharmacy 18 and financial system 21) via interface engine 19. 

Figure 3 shows a user interface display window for use indicating 
events, associated parameters, executable procedures and other data that are 
usable in initiating or altering workflow processes comprising scheduled task 
sequences. The menu display image of Figure 3 is derived by HIS 12 (Figure 2) 
using an Extensible Markup Language (XML) document though in other 
embodiments the user interface of Figure 3 may be derived based on other 
language files such as HTML, SGML eta* The Figure 3 user interface includes 
prompt element 630 that presents a fist of workflow processes available for 
selection. This enables a user to associate a workflow process such as 
Gentamicin Management selected via prompt element 630 with events such as a 
Gentamicin order 603 selected from hierarchically arranged events via prompt 
element 6Q0. The user interface also enables a user to associate the selected 
workflow process (Gentamicin Management) with event parameters derived from 
HIS 12 (Figure 2) and an executable procedure to be conveyed to the workflow 
process management routine upon occurrence of the selected event (here an 
order for Gentamicin). The event parameters from HIS 12 are mapped into 
corresponding parameters of the associated workflow process. The event 
parameters and executable procedure are selected for association with the 
selected workflow process via prompt elements 611 and 633 respectively. The 
Figure 3 user interface enables an order with a parameter value associated with 
patient discharge to be used to initiate a patient discharge procedure, for 
example. As another example, a pharmacy order for Gentamicin IV may be used 
to initiate an aminoglycoside infusion process. 

Particular event parameters such as the patient's identifier number 
(PTID) 612, dose (for example, 1 ml or 2 tablets) 620, time (for example, every 8 
hours) 618, route (for example, intravenous) 616, and strength (for example f 80 
mg/ml or 500 mg) 614 are selected via prompt element 611 which also indicates 
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the corresponding identification label employed by the workflow process. The 
Gentamicin workflow process parameter label PTID 610 corresponds to the same 
label PTID 612 employed by HIS 12, for example. The workflow and HIS labels 
need not be the same in other cases and prompt element 611 advantageously 
presents to a user the parameter mapping of an HIS label to a corresponding 
workflow process label and enables a user to verify that the mapping is correct 
and to amend the mapping if required. Further, a user is able to select via 
selection item 625 whether a default workflow process is to be replaced by the 
event associated workflow process selected via prompt element 630. Selection of 
item 625 results in replacement of a scheduled default workflow process (or in 
another embodiment, particular identified tasks of the default workflow process) 
with the event associated workflow process selected via prompt element 630. 
Non-selection of item 625 results in the default workflow process being 
supplemented by the event associated workflow process. Such supplementing of 
a default workflow process may take the form of the event associated workflow 
process running entirety in addition to the default process or may comprise the 
addition of some task steps to the default process. Further, although not shown in 
the Figure 3 user interface (to preserve drawing clarity), a user is able to select 
event parameter values for use as selection criteria for process initiation. For 
example, a workflow process can be registered for Ampicillin . Thereby a workflow 
process may be initiated if Ampicillin is ordered and can be configured to apply 
only if the administration route is intravenous. In addition, although not shown to 
preserve drawing clarity, the user interface of Figure 3 may include an image 
element for prompting a user to select a default process that is to be modified or 
replaced and to associate this selected default process with an event associated 
workflow process. In another embodiment (and also not shown), the Figure 3 user 
interface also allows a user to view the selected default process tasks and to 
select particular tasks to be modified by the event associated workflow process. 

Figure 4 shows a process flowchart for use by event processor 28 
(Figure 2) for replacing one or more tasks of a scheduled workflow process with 
event associated tasks* In step 303 after the start at step 300, event processor 28 
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receives a message (e.g. from HIS 12 Figure 2) identifying occurrence of an 
event. Processor 28 applies predetermined rules in step 308 to determine 
particular tasks to be performed in response to the identified event. Event 
processor 28 examines predetermined user selected information identifying those 
of the particular tasks that are to be added to an existing workflow process and 
those of the particular tasks that are to be substituted for existing tasks in the 
existing workflow process. The identified additional tasks are added to the existing 
workflow process in step 310 and the identified substitute tasks are substituted for 
the existing tasks in step 313. Further, the particular tasks are scheduled for 
performance as part of the existing workflow process by an entity such as an 
individual, group of individuals or personnel assigned to a role or another 
arrangement of personnel in step 315 and the process of Figure 4 ends at step 
319. 

Figure 5 shows a process flowchart for processing an event and 
associated parameters for use in replacing a scheduled workflow process with an 
event associated workflow process. In step 403 after the start at step 400 event 
processor 28 (Figure 2) receives one or more messages (e.g. from HIS 12) 
identifying occurrence of an event as well as an associated parameter, process 
and instance of the process and also including a value of the event associated 
parameter. As previously explained an instance of a process is a copy of a 
workflow process and may comprise a particular use of the process for a specific 
patient, for example. Processor 28 applies predetermined rules in step 405 to 
interpret the identified event to select in step 409 a particular process (comprising 
predetermined tasks) from a plurality of predetermined processes. In step 411 
processor 28 creates an instance of the selected predetermined process and 
provides this instance with the parameter values previously received in step 403. 
Processor 28 In step 414 schedules performance of the selected workflow 
process instance by an entity (e.g. at least one individual) to replace a scheduled 
workflow process. The process of Figure 5 is complete at step 417. 

As an example, the Figure 2 system is considered in operation in 
conjunction with a configured IV antibiotic infusion workflow process. The user 
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interface described in connection with Figure 3 is empfoyed to associate the 
antibiotic infusion workflow process with events comprising orders of a medication 
which have a drug type that is an antibiotic and a route that is Intravenous. This 
workflow process is designated to replace a default system process (e.g. following 
selection of icon 625 of Figure 3). Therefore, in response to a physician placing 
an order for Gentamicin 120 mg IV for patient 1234, HIS 12 (Figure 2) generates 
an event message indicating that Patient 1234 is the subject of a drug order for 
drug name "Gentamicin" specifically, drug type "aminoglycoside antibiotic", dose 
strength 120 mg , route IV. Event processor 28 receives the event message and 
determines that it has one or more subscribed predefined processes and that at 
least one of them is to replace the default system workflow process. Event 
processor 28 communicates a return message to HIS 12 to indicate that HIS 12 is 
not to proceed with the default workflow process but instead processor 28 is to 
implement a substitute a workflow process previously associated with the event 
via the Figure 3 user interface. This return message is incorporated in the event 
acknowledgment message but in other embodiments multiple separate messages 
may be used. Event processor 28 maps data parameters received in the event 
message from HIS 12 to corresponding parameters required by the event 
associated substitute workflow process. In addition the event processor initiates 
creation and scheduling of processing of an instance of the substitute workflow 
process using rules engine 30 and workflow management system 36 (Figure 2), 

In a further example, the user interface described in connection with 
Figure 3 is employed to associate an IV infusion workflow process with an "IV 
infusion failure" event for a particular patient Identifier and a particular drug. Upon 
failure of a smart IV infusion pump to infuse the particular drug because of air in 
the line, the pump communicates an event message indicating "IV infusion failure" 
to event processor 28. The event message a!so includes pump identifier, patient 
identifier and drug parameter information derived from storage associated with the 
smart pump device. Event processor 28 determines that it has several workflow 
processes associated with the "IV infusion failure" event and accompanying 
particular received patient identifier and drug identifier. Thereupon, processor 28 
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initiates a call to the running instances of the event associated workflow 
processes with the particular received patient identifier and drug identifier using 
parameters derived from the IV infusion workflow process involving the "IV 
infusion failure" event. The notified workflow process modifies its behavior based 
upon the notification, and includes the scheduling of alerting a nurse to have the 
problem corrected. 

Figure 6 shows a workflow and event management system 
responsive to events 46 generated by other workflow processes and responsive 
to events 47 external to an HIS. This provides enhanced capabilities for managing 
healthcare workflow, Thereby, for example, medication IV pumps, upon 
completion of infusion, may communicate an event message {including 
predetermined patient and medication identifiers stored by the pump) to event 
monitor 25. In response, event monitor 25 initiates an event associated workflow 
process that efficiently implements a predetermined healthcare regimen following 
infusion, and/or notifies running process instances of the occurrence of events for 
which they have registered interest. Similarly, patients may be provided with 
location or proximity detector badges enabling event messages to be generated 
upon a change in location of a patient and further promoting efficient care. In 
addition, in the Figure 6 system, a first workflow process is configurable to 
generate an event message and communicate it to event monitor 25 for modifying 
a, different second (or more) workflow process. Such an event message may 
include parameters identifying change in a patient location, patient status or nurse 
availability, for example. 

The inventors have recognized that a problem arises in workflow 
management systems that constrain particular parameters or status indications to 
be exclusively associated with particular workflow process instances. Further that 
there is an advantage in employing global event associated parameters. Such a 
global event parameter may be associated with, and accessed by, more than one 
workflow process and process instance. This prevents the problem of having 
multiple workflow processes that interact potentially using a common event 
associated parameter with different incompatible values. Such a problem arises, 
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for example, if a parameter indicating a location of a specific patient set within a 
first running workflow process, is different to another location indication for the 
same patient maintained in a second process. This may occur for a variety of 
reasons such as if the patient location indication is updated at different intervals 
by the first and second processes or by use of a different location identification 
scheme by the first and second processes- The use of an individual global even! 
parameter accessible from multiple running workflow processes prevents this 
problem. Thereby, a patient global event parameter indicating location (or other 
information item), stored at a single point, may be advantageously updated and 
accessed from multiple workflow processes based on a common patient identifier, 
for example. 

In response to receiving an event message 46 or 47 and in similar 
fashion to the system of Figure 2, event monitor 25 (Figure 6) examines an 
interna! map to determine whether a workflow process is associated with an event 
identified by an event identifier. If the identified event is associated with a 
particular workflow process (decision 34), it is determined whether the event 
associated workflow process is to be implemented. For this purpose event 
monitor 25 determines whether any received event parameter values or globally 
accessible event parameter values identified in the received event messages 46 
or 47 are within an acceptable predetermined range. If the received parameters 
are acceptable and the event associated workflow process is to be implemented, 
event monitor 25 provides rules engine 30 with the event identifier and associated 
event parameter (including global parameter) values for use in implementing the 
particular workflow process. Rules engine 30 determines whether other event 
associated workflow process implementation pre-conditions are satisfied and 
support implementation of the event associated workflow process. Such pre- 
conditions include conditions derived from an executable procedure associated 
with the event associated workflow process, for example. The operation of the 
remainder of the Figure 6 system is the same as for the system described in 
connection with Figure 2. Specifically, rules engine 30 uses the information 
received from monitor 25 to call the Workflow Management System 36 and 
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instruct it to implement the event associated particular workflow process 31. The 
implemented workflow process may also communicate with users and other 
systems (e.g. laboratory 17, pharmacy 18 and financial system 21) via interface 
engine 19. 

Figure 7 shows a currently operating Healthcare Information System 
(HIS) workflow process responsive to a predetermined event generated by 
another workflow process. It is known for workflow management systems to 
employ within a workflow process (comprising tasks 800-815) a special workflow 
task termed a "process event step" 807 that may be directly referenced and 
initiated within a currently operating workflow process. In order to initiate special 
event step 807, a calling application provides the workflow process with a process 
identifier, a specific process instance identifier and an event step Identifier (e.g., 
identifying step 807). Further, such a process event step may be used to initiate a 
task sequence path (comprising tasks 807, 809, 810, 804 and 815) that is 
different to the normal workflow process task sequence path (comprising tasks 
800, 803, 804 and 815). Thereby, providing a modified workflow process. 

However, the inventors have recognized that existing workflow 
management systems are limited in the use of the process event step feature. 
This is because process instance identifiers are generated when copies 
(instances) of workflow processes are dynamically generated. They are not 
known in advance. Known systems typically require that in order to call such a 
process event step, the calling parameters (process identifier, a specific process 
instance identifier and an event step identifier) are predetermined and stored at 
the time they are associated with events generated from an HIS or other workflow 
processes. Consequently, subsequently dynamically created copies (instances) of 
a workflow process, including a process event step, have different unrecognized 
process instance identifiers. Therefore, such subsequently created process 
instances do not respond to event messages and are not initiated upon 
occurrence of an event associated with the original process. The system of Figure 
8 addresses this deficiency. 
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Figure 8 shows a system for processing an event indication affecting 
a currently operating instance of a Healthcare Information System (HIS) workflow 
process. In the Figure 8 system, upon initiation of an instance of workflow process 
31 event monitor 25 is provided with its process identifier, its specific process 
instance identifier and its process event step identifier (or multiple process event 
step identifiers if they exist). Upon receiving an event message, event monitor 25 
determines that the event identified by the received message is associated with 
workflow process 31 (decision 34). Further, event monitor 25 identifies any 
currently operating or scheduled instances of process 31 (decision 905). This is 
determinable since all instance identifiers of corresponding instances of process 
31 have been provided to monitor 25 upon their initiation, or monitor 25 can query 
Workflow Management System 36 for this information when needed. Event 
monitor 25 also determines which of the Identified currently operating instances of 
the identified event associated workflow process 31 are to be implemented based 
on criteria previously explained In connection with Figure 2. Thereupon, event 
monitor 25 provides rules engine 30 with the event identifier and associated event 
parameter (including global parameter) values for use in implementing the 
particular workflow process 31 instances. Rules engine 30 uses the information 
received from monitor 25 to validate the process initiation and instruct Workflow 
Management System 36 to implement the event associated particular workflow 
process 31 instances* 

As an example, If a dietary workflow process Is associated with an 
event comprising a "nothing by mouth" order, event monitor 25 determines 
whether there is a running instance of the dietary workflow process for the same 
patient that is the subject of the "nothing by mouth" order, it does this using an 
internal database tracking operating process Instances and associated process, 
instance and process event step identifiers as well as associated event 
parameters, executable procedures and other event related data. Event monitor 
25 uses the identifiers in instructing rules engine 30 to call an appropriate process 
event step within the identified operating process instance. This event processing 
method provides a flexible, efficient and dynamically alterable workflow process 
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management system. Using thfs system, workflow processes incorporating one or 
more process event steps may be devised that may be dynamically selected in 
response to an array of different events (internal and external to an HIS) occurring 
in a healthcare environment. For example, using multiple process event steps and 
such an event processing system an individual operating workflow process may 
comprise multiple different scheduled task sequences that are each selectable in 
response to occurrence of corresponding particular healthcare events. As a result 
operating workflow processes are dynamically modifiable in response to events 
occurring In the course of a patient treatment or diagnosis regimen. This 
contributes to providing an efficient flexible and responsive healthcare system. 

The architectures and processes presented in Figures 1-8 are not 
exclusive. Other architectures and processes may also be derived in accordance 
with the principles of the invention to accomplish the same objectives. Further, the 
inventive principles may be advantageously employed in any workflow processing 
system responsive to events and is not limited to use in the healthcare field. 
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What is claimed is: 

1 . In a system for scheduling a first process, comprising a set of 
tasks, to be performed by at least one individual to support healthcare delivery, a 
method for processing an event representing a change in circumstances 
potentially affecting healthcare delivered to a patient, comprising the steps of: 

receiving a message identifying occurrence of an event potentially 
affecting healthcare delivered to a patient; 

in response to said occurrence of said identified event, 
determining particular tasks to be performed; and 
initiating scheduling of performance of said particular tasks by 
at least one individual. 

2. A method according to claim 1, including 

fn response to examining predetermined information and said 
occurrence of said identified event, performing at feast one of the steps of 

(a) adding said particular tasks to an existing scheduled task 
sequence, and 

(b) substituting at least one of said particular tasks for a task of an 
existing scheduled task sequence. 

3. A method according to claim 1, wherein 

said message includes an event identifier identifying said event and 
is generated by a second process comprising a second set of tasks and including 
the step of 

also receiving at least one of, (a) a process identifier, (b) an 
identifier identifying a particular instance of said first process. 

4. A method according to claim 3, wherein 

said particular instance of said first process comprises a particular 
use of said process for a specific patient. 
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5. A method according to claim 1 , including the steps of 

filtering a plurality of received messages to identify said message 
identifying occurrence of an event potentially affecting healthcare delivered to a 
patient and 

excluding other messages immaterial to said healthcare delivered to 

said patient. 

6. A method according to claim 5, including the step of 

filtering said plurality of received messages based on an event 

identifier. 

7. A method according to claim i, wherein 

said message includes an event identifier identifying said event and 
a process identifier identifying a target process to be replaced by a predetermined 
process comprising said particular tasks. 

8. A method according to claim 7, and including the step of 
searching a database containing records indicating active processes 

and process instances to identify active process instances of said target process 
to be replaced. 

9. A method according to cfaim 1, wherein 

said event comprises at least one of, (a) an event resulting from 
action by healthcare personnel, (b) an event generated by an operating process, 
(c) an event generated by patient monitoring equipment and (d) an event 
generated by a medical device. 

10. A method according to claim 1, including the step of 
receiving information identifying a particular individual task of an 

existing scheduled task sequence and including the step of 

adapting said existing scheduled task sequence by initiating 
processing of said existing scheduled task sequence from said identified 
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particular individual task in response to occurrence of said event. 
1 1, A method according to claim 1, wherein 

said particular tasks comprise a predetermined process and said 
message identifies at least one parameter associated with sard event and 
including the step of 

determining whether said identified event Is associated with a 
predetermined process of a plurality of predetermined processes, and 

providing said parameter to said predetermined process in response 
to said determination. 



12. A method according to claim 1 1, wherein 

said associated parameter is for use by muftipie different process 
task sequences and is stored at a location available for access by said multiple 
different process task sequences. 

13. A method according to claim 11, including the step of 
verifying said associated parameter is compatible with 

predetermined value criteria as a pre-condition to providing said parameter to said 
predetermined process. 

14. A method according to claim 1 1, including the step of 
replacing scheduling of performance of another process with said 

scheduling of performance of said identified process. 

15. A method according to claim 1, wherein 

in response to occurrence of an event in a first process, and 
including the steps of, 

receiving at least one message identifying said event occurring 
during said first process and identifying a parameter associated with said event; 

acquiring said parameter associated with said first process event 
and providing said acquired parameter to a second process; and 

adapting sard second process by scheduling performance of a 
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particular set of tasks in response to receiving said at least one message. 

1 6. A method according to claim. 1 5, 

including the step of receiving an identifier identifying a particular 
individual task in said second process and wherein 

said adapting step comprises initiating processing of said second 
process from said particular individual task in response to receiving said at least 
one message. 

17. A method according to claim 15, wherein 

said parameter associated with said event is stored at a location 
available for access by said first and second processes. 

18. A method according to claim 15, including the step of 

sharing data between said first and second process comprising 
sharing at least one of, (a) an event identifier identifying said event, (b) a process 
identifier identifying said first process, (c) an identifier identifying a particular 
instance of said first process and (d) an identifier identifying a particular individual 
task in a process. 
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RECEIVE A MESSAGE IDENTIFYING AN EVENT, 



303 



APPLY PREDETERMINED RULES TO INTERPRET THE 
IDENTIFIED EVENT TO DETERMINE PARTICULAR TASKS TO 
BE PERFORMED IN RESPONSE TO OCCURRENCE OF THE 
IDENTIFIED EVENT. 
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ADD THE PARTICULAR TASKS TO AN 
EXISTING SCHEDULED TASK SEQUENCE. 



REPLACE A TASK OF THE EXISTING 
SCHEDULED TASK SEQUENCE WITH ONE OF THE 

PARTICULAR TASKS. i 






INITIATE SCHEDULING 0 
PARTICULAR TASKS BY A 
IN RESPONSE TO OCCU 


r PERFORMANCE OF THE 
T LEAST ONE INDIVIDUAL 
RRENCE OF THE EVENT. 



315 




FIG. 4 



WO 03/023551 



PCT/US02/23496 



5/7 




RECEIVING A MESSAGE IDENTIFYING, AN EVENT, A PROCESS, 
AND AN INSTANCE OF THE PROCESS AND A PARAMETER 
ASSOCIATED WITH THE EVENT. 
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APPLY PREDETERMINED RULES TO 
INTERPRET THE IDENTIFIED EVENT. 



DETERMINE WHETHER THE IDENTIFIED EVENT IS 
ASSOCIATED WITH A PREDETERMINED PROCESS 
OF A PLURALITY OF PREDETERMINED PROCESSES. 



PROVIDE THE RECEIVED PARAMETER TO THE PREDETERMINED 
PROCESS IN RESPONSE TO THE DETERMINATION. 



INITIATE SCHEDULING OF PERFORMANCE OF THE 
PREDETERMINED PROCESS BY AT LEAST ONE INDIVIDUAL 
IN RESPONSE TO OCCURRENCE OF THE IDENTIFIED EVENT 
TO REPLACE SCHEDULED PERFORMANCE OF ANOTHER PROCESS. 
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